SECTION III— REMARKS 

This amendment is submitted in response to the Office Action mailed December 15, 
2005. No claims are amended, and claims 37-70 and 72 remain pending in the application. 
Applicants respectfully request reconsideration of the present application in view of the 
following remarks. 

Rejections Under 35 U.S.C. S 103 

The Examiner rejected all claims in the application under 35 U.S.C. § 103(a) as obvious 
in view of, and therefore unpatentable over, various combinations of the following references: 
U.S. Patent No. 6,144,638 to Obenhuber et al ("Obenhuber"); Demuth et al, Securing the 
anonymity of content providers in the World Wide Web, Abstract of Proceedings of the SPIE, 
vol. 3657, pp. 494-502 (1999) ("Demuth"); and M. Farah, Encrypted Hypertext Transfer 
Protocol - UGGC/LO, Network Working Group, pages 1-5 (April 2000) ("Farah"); and U.S. 
Patent No. 6,502,106 to Gampper et al ("Gampper"). 

Applicants respectfully traverse the Examiner's rejections. Prior art disclosures on the 
Internet or on an on-line database are considered to be publicly available as of the date the item 
was publicly posted. MPEP § 2128. Applicants submit that Farah is not a proper prior art 
reference because it was not posted on the Internet prior to the May 26, 2000, filing date of the 
present application. 

Farah has a date of April 1, 2000, written on it, but there is no evidence whatsoever that 
this is the date the document was publicly posted; in fact, there is evidence that Farah was not 
publicly posted until sometime near the end of July 2000. Farah indicates that it was written for 
posting on the Internet Engineering Task Force (IETF) website (www.ietf.org) . According to 
IETF rules (see attachment A, section 8), a document expires and is withdrawn exactly 1 85 days 
after posting. A search of the archives on the IETF website indicates that Farah expired on 
January 31, 2001 (see attachment B). Since Farah expired on January 31, 2001, the earliest it 
could have been posted is 185 days before, which is approximately July 25, 2000. Thus, despite 
the April 1, 2000, date on the document, Farah was not publicly posted until after the 
Applicants' filing date of May 26, 2000. The Examiner found Farah on the website 
"quimby.gnus.org," which claims that its archive mirrors that of the IETF website. This means 
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that the earliest Farah could have appeared on the quimby site is also approximately July 25, 
2000, although it likely appeared later because of normal delays in synchronizing the site. 

In view of the above, Applicants submit that Farah is not a proper prior art reference. 
Since every one of the Examiner's rejections depends on Farah, Applicants submit that all the 
Examiner's rejections are overcome by the disqualification of Farah. Applicants therefore 
respectfully request withdrawal of the rejections and allowance of the claims. 

Conclusion 

Given the above remarks, all claims pending in the application are in condition for 
allowance. If the undersigned attorney has overlooked a teaching in any of the cited references 
that is relevant to allowance of the claims, the Examiner is requested to specifically point out 
where such teaching may be found. Further, if there are any informalities or questions that can 
be addressed via telephone, the Examiner is encouraged to contact the undersigned attorney at 
(206) 292-8600. 

Charge Deposit Account 

Please charge our Deposit Account No. 02-2666 for any additional fee(s) that may be due 
in this matter, and please credit the same deposit account for any overpayment. 

Respectfully submitted, 

BLAKELY, SOKOLOFF, TAYLOR & ZAFMAN LLP 

Date: S'tS~tt> <fo * &C ^¥ \ ^4§^^^ 

Todd M. Beckers- 
Attorney for Applicant(s) 
Registration No. 43,487 

Blakely, Sokoloff, Taylor & Zafinan LLP 
12400 Wilshire Boulevard, Seventh Floor 
Los Angeles CA 90025-1030 
Phone: 206-292-8600 
Facsimile: 206-292-8606 

Enclosures: Postcard 

Amendment transmittal, in duplicate 
Petition for two-month extension of reply period 
Check for small entity extension fee 
Attachment A (10 pages) 
Attachment B (3 pages) 
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1. Submissions 

ALL submissions to the Internet-Draft directories must be sent to internet- 
drafts@ietf.org. 

The Internet-Draft may be sent as an attachment to the email, or the email may 
contain a URL which points to a copy of the Internet-Draft stored on a server. 

DO NOT SEND ZIP files. We will not open them. 
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2. General Considerations 

The Internet- Drafts directories are available to provide authors with the ability to 
distribute and solicit comments on documents they may eventually submit to the 
IESG or RFC Editor for publication as an RFC. Internet-Drafts are not an archival 
document series. These documents should not be cited or quoted in any formal 
document. Unrevised documents placed in the Internet-Drafts directories have a 
maximum life of 185 days. After that time, they must be updated, or they will be 
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deleted. See RFC 2026[RFC2026] for more information. In exceptional 
circumstances, an extension of this lifetime is possible; see Section 8 below. After 
a document becomes an RFC, it will be replaced in the Internet-Drafts directories 
with an announcement to that effect. 

Internet-Drafts are generally in the format of an RFC, although they may be rough 
drafts when the first version is submitted. This format is specified fully in 
"Instructions to RFC Authors" (see t he RFC Editor's We b pages and [I-D.rfc- 
editor-rfc2223bis]). In brief, an Internet-Draft must be submitted in ASCII text, 
and should be limited to 72 characters per line and 58 lines per page, followed by a 
formfeed character. Overstriking to achieve holding or underlining is not 
acceptable. 

PostScript and/or PDF are acceptable, but only when submitted with a matching 
ASCII version (even if figures must be deleted). PostScript and PDF should be 
formatted for use on 8.5x11 inch paper. If A4 paper is used, an image area no 
greater than 254mm high should be used to avoid printing extra pages when 
printed on 8.5x11 paper. 

There are differences between the RFC and Internet-Draft format. Internet-Drafts 
are NOT RFCs and are NOT a numbered document series. The words "INTERNET- 
DRAFT" should appear in the upper left hand corner of the first page. The 
document should NOT refer to itself as an RFC or a draft RFC. 

The Internet-Draft should neither state nor imply that it has any standards status; 
to do so conflicts with the role of the RFC Editor and the IESG. The title of the 
document should not imply a status. Avoid the use of the terms Standard, 
Proposed, Draft, Experimental, Historic, Required, Recommended, Elective, or 
Restricted in the title of the Internet-Draft. Indicating what status the document is 
aimed for is OK, but should be done with the words "Intended status: <status>". 
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3. IPR-Related Notices Required in Internet-Drafts 

All Internet-Drafts must have the following intellectual property rights (IPR) 
statement on the first page: 

"By submitting this Internet-Draft, each author represents that any applicable 
patent or other IPR claims of which he or she is aware have been or will be 
disclosed, and any of which he or she becomes aware will be disclosed, in 
accordance with Section 6 of BCP 79." 

(See RFC 3978[RFC3978] section 5.1.) 

All Internet-Drafts must include the following statements near the end of the 
document: 

"Copyright (C) The Internet Society (YYYY). 
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This document is subject to the rights, licenses and restrictions contained in BCP 
78, and except as set forth therein, the authors retain all their rights." 

"This document and the information contained herein are provided on an "AS IS" 
basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS 
SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 

(See RFC 3978[RFC3978] sections 5.4 and 5.5.) "YYYY" in the copyright 
statement should be replaced with the current year. 

Any submission which does not include these statements will be returned to the 
submitter. The IETF Secretariat will NOT add this text. 

Note that although these statements appear to be written in English, they are 
actually written in lawyerese. Although it's awfully tempting to modify them, e.g., 
to remove "or she" in a document that has only male authors, please don't. It adds 
too much overhead to the Internet-Draft submission process to evaluate any given 
boilerplate variation to decide whether or not it changes the meaning. 
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4. Optional IPR-Related Notices that May Be Included in Internet-Drafts 

If the submitter desires to eliminate the IETF's right to make modifications and 
derivative works of an Internet-Draft, one of the following two notices may be 
included after the IPR statement: 

a 

"This document may not be modified, and derivative works of it may not 
be created, except to publish it as an RFC and to translate it into 
languages other than English." 

b 

"This document may not be modified, and derivative works of it may not 
be created." 

In the cases of MIB or PIB modules and in other cases where the Contribution 
includes material that is meant to be extracted in order to be used, the following 
should be appended to the above statements: 

"other than to extract section XX as-is for separate use." 

Statement (a) is used if the contributor intends for the Internet-Draft to be 
published as an RFC. Statement (b) is used along with the publication limitation 
statement below when the contributor does not intend for the Internet-Draft to be 
published as an RFC. 
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These notices may not be used with any standards-track document or with most 
working group documents, except as discussed in RFC 3978[RFC3978] section 
7.3, since the IETF must retain change control over its documents and the ability to 
augment, clarify and enhance the original contribution in accordance with the IETF 
Standards Process. 

Statement (a) may be appropriate when republishing standards produced by other 
(non-IETF) standards organizations, industry consortia or companies. These are 
typically published as Informational RFCs, and do not require that change control 
be ceded to the IETF. Basically, documents of this type convey information for the 
Internet community. (See RFC 3978[RFC3978] sections 5.2 and 7.3.) 

If the Contributor only wants the contribution to be made available in an Internet- 
Draft (i.e., does not want the Internet-Draft to be published as an RFC) then the 
contributor may include the following publication limitation statement after 
Statement (b): 

"This document may only be posted in an Internet-Draft." 

This notice can be used on Internet-Drafts that are intended to provide background 
information to educate and to facilitate discussions within IETF working groups but 
are not intended to be published as an RFCs. (See RFC 3978[RFC3978] section 
5.3.) 
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5. Internet-Draft Boilerplate 

The following verbatim statement must follow the IPR statement and optional 
notices (if any): 

"Internet-Drafts are working documents of the Internet Engineering Task Force 
(IETF), its areas, and its working groups. Note that other groups may also 
distribute working documents as Internet-Drafts. 

Internet-Drafts are draft documents valid for a maximum of six months and may 
be updated, replaced, or obsoleted by other documents at any time. It is 
inappropriate to use Internet-Drafts as reference material or to cite them other 
than as "work in progress." 

The list of current Internet-Drafts can be accessed at http://www.ietf.org/lid- 
abstracts.html 

The list of Internet-Draft Shadow Directories can be accessed at 
http://www.ietf.org/shadow.html" 

Any submission which does not include these statements will be returned to the 
submitter. The IETF Secretariat will NOT add this text. 
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6. Formatting 

Every Internet-Draft must have an Abstract section. The Abstract should provide a 
concise and comprehensive overview of the purpose and contents of the entire 
document. Its purpose is to give a technically knowledgeable reader a general 
overview of the function of the document, to decide whether reading it will be 
useful. In addition to its function in the document, the Abstract section is used as a 
summary in publication announcements and in the online index of Internet- 
Drafts . 

Composing a useful Abstract is a non-trivial writing task. Often, a satisfactory 
abstract can be constructed in part from material from the Introduction section, 
but a good abstract will be shorter, less detailed, and broader in scope than the 
Introduction. Simply copying and pasting the first few paragraphs of the 
Introduction is tempting, but it generally results in an Abstract that is both 
incomplete and redundant. 

An Abstract will typically be 5-10 lines, but an Abstract of more than 20 lines or 
less than 3 lines is generally not acceptable. 

An Abstract should be complete in itself, so it should contain no citations unless 
they are completely defined within the Abstract. Abbreviations appearing in the 
Abstract should generally be expanded in parentheses. There is a small set of 
reasonable exceptions to this rule; for example, readers don't need to be reminded 
of what "IP" or "TCP" or "MIB" means. In the end, therefore, this is a judgment 
call, but please err on the side of explicitness. 

In addition, the Internet-Draft should contain a section giving name and contact 
information (postal mail, voice/fax number and/or e-mail) for the authors. 

All Internet-Drafts must contain the full filename (beginning with draft- and 
including the version number) in the text of the document. The filename 
information should, at a minimum, appear on the first page (possibly with the 
title). Internet-Draft filenames use lowercase characters ONLY. See Section 7 for 
more information on filenames. 

It is strongly recommended that the draft include a notice (with email address) of 
where comments should be sent. For example, "Comments are solicited and should 

be addressed to the working group's mailing list at @ and/or the author 

(s)." 

A document expiration date should appear on the first and last page of the 
Internet-Draft. The expiration date is 185 following the submission of the 
document as an Internet-Draft. Use of the phrase "expires in six months" or 
"expires in 185 days" is not acceptable. 

Internet-Drafts must be in ASCII. No 8-bit characters are currently allowed. If you 
need to include code points, a suggestion might be to use the Unicode convention: 
U+XXXX, where X is a hexadecimal digit. 
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If the Internet-Draft is longer than about 15 pages, please include, on the second 
page, a table of contents to make the document easier to reference. 
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7. Naming and Submitting 

Internet-Draft filenames have four parts, separated with hyphens and which may 
themselves contain hyphens: 

1. All Internet-Draft filenames begin with "draft" 

2. Document source: 

Individual 

The name of the submitter (one of the authors). This can 
be a surname, a given name, or an email address used by 
an author, as specified in the Authors' Addresses section of 
the draft. 
Working Group 

The string "ietf-" followed by the working group acronym. 

Other 

A string identifying an IETF-related body, such as "iab", 
"iesg", "rfc-editor". 

Note that although other variations of "Other" have been used in the 
past which have no direct relationship with one of the authors (most 
famously, "ymbk"), these are no longer permitted. Company and 
organization names are also not permitted. 

3. Document name. For non-working group documents that are targeted at a 
working group, this string often begins with the working group abbreviation. 
This document name is a word or two that reflect what the draft is about. 

4. Two digit decimal version number, starting with 00. 

Note that the limit on the total length of a filename excluding the version number 
is 50 characters, and the only characters allowed in a filename are lowercase 
letters, numerals and hyphens. Internet-Draft filenames are never reused; if a 
previous document has used your desired filename you must pick another. 

For those authors submitting updates to existing Internet-Drafts, the choice of the 
file name is easily determined (up the version by 1). For new documents, submit 
the document with a suggested filename following the above rules. Note that if the 
suggested filename is not acceptable for some reason (e.g., not getting working 
group chair approval for a working group document), the document will have to be 
resubmitted with the actual file name. 

If the document is a new one (i.e., starting with revision -00.txt) and is submitted 
as a working group document, the IETF Secretariat needs permission from the 
chair(s) of the wg to publish it as a working group document. Working group chairs 
should submit this permission at (or close to) the time that the draft is submitted 
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for posting. To expedite the process, authors are encouraged to send the document 
to "internet-drafts@ietf.org" and at the same time cc: to the chair(s) of the 
working group. If the document is accepted as a working group document, then it 
will have the draft-ietf-<working group acronym> file name and will be announced 
on the working group mailing list by the IETF Secretariat. If the document is not 
accepted as a working group document, it will be processed as an individual 
submission, where the filename will be draft-<yourname> / as described above. 

NOTE: Revision numbers are based on the filename (as in first, second, or third 
version of this document). If there is a filename change, the version number starts 
over at -00. Put another way, the prior version number will NOT be incremented 
when an Internet-Draft filename has changed, e.g., from an individual to a working 
group document. ALL FILES BEGIN at -00. 

Before each IETF meeting, a deadline is announced for submitting documents 
ahead of time to be published for the meeting. For new documents, the deadline is 
one week earlier than for new versions of old drafts. Care should be taken when 
submitting an Internet-Draft near the deadline. The Secretariat includes a "grace 
period" after the cutoff time; while the auto response message changes right at the 
cutoff time, submissions that are received by the Secretariat during the grace 
period will still be posted. This grace period is normally more than sufficient to 
ensure that documents submitted close to the deadline are received and accepted 
for posting. The Secretariat receives hundreds of Internet-Drafts immediately 
preceding an IETF meeting, and it can take several days to process and post them 
all. If an Internet-Draft that was submitted very close to the deadline has not been 
posted and announced within three days, then the submitter should send a 
message to ietf-action@ietf.org (using the suggested subject line "Status of I-D 
Submission: <filename>") and reference the auto-response acknowledgement for 
the document in the body of the message. The Secretariat will be happy to 
investigate the situation and post any valid submission that was not posted in the 
first round. 

When you submit an Internet-Draft, you will receive an auto-response message 
from the Secretariat acknowledging that your Internet-Draft has been received. 
The subject line of the message will read: [Auto Response] <subject of your 
original message>. If you do not receive an acknowledgement within 2 hours after 
submitting your Internet-Draft, then please contact the Secretariat by sending a 
note to "ietf-action@ietf.org". The suggested subject line for this note is: "Status of 
I-D Submission: <filename>". If you need to track the status of your Internet- 
Draft at a later date, then please send a note to "ietf-action@ietf.org" (using the 
suggested subject line "Status of I-D Submission: <filename>") and include the 
auto-response acknowledgement for your document in the body. 
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8. Expiring 

An Internet-Draft will expire exactly 185 days from the date that it is posted on the 
IETF Web site (< htt p://w ww.ietf.or g /ID.html >) unless it is replaced by an 
updated version (in which case the clock will start all over again for the new 
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version, and the old version will be removed from the Internet-Draft directories), 
or unless it is under official review by the IESG (i.e., a request to publish it has 
been submitted). Specifically, when an Internet-Draft enters the "Publication 
Requested" state in the I-D Tracker, it will not be expired until its status is resolved 
(e.g., it is published as an RFC). I-D Tracker states not associated with a formal 
request to publish a document (e.g., "AD is Watching") will not prevent an 
Internet-Draft from expiring after 185 days. 

Internet-Drafts will not expire during the period surrounding an IETF meeting when 
posting of updates to Internet-Drafts is suspended (i.e., between the cutoff date 
for submission of updated drafts, which is two weeks prior to an IETF meeting, and 
the date that posting of Internet-Drafts resumes). All Internet- Drafts scheduled to 
expire during this period will expire on the day that the Secretariat once again 
begins posting Internet-Drafts. 

When an Internet-Draft expires, a "tombstone" file will be created that includes the 
filename and version number of the Internet-Draft that has expired. The filename 
of the tombstone file will be the same as that of the expired Internet-Draft with the 
version number increased by one. If a revised version of an expired Internet-Draft 
is submitted for posting, then the revised version will replace the tombstone file 
and must have the same version number as that previously assigned to the 
tombstone file. Tombstone files will never expire and will always be available for 
reference unless they are replaced by updated versions of the subject Internet- 
Drafts. 

An expired Internet-Draft may be unexpired when necessary to further the IETF's 
work, including IETF liaison with other standards bodies. Such action will be taken 
by request of an IESG member, a working group chair of the Internet-Draft's 
working group, or one of the document authors. Such a request may be 
overridden; e.g., a working group chair of the Internet-Draft's working group will 
be notified if an author requests unexpiration and may request that the action not 
occur. This request should be sent to "internet-drafts@ietf.org" (using the 
suggested subject line "Resurrect I-D <filename>") and should be from an author, 
a working group chair or an IESG member. 

The expiration date of an unexpired Internet-Draft may be extended with the same 
rules as unexpiration. This request should be sent to "internet- 
drafts@ietf.org" (using the suggested subject line "Extend expiration date for 
<filename>") and should be from an author, a working group chair or an IESG 
member. 
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9. Intellectual Property Rights 

If you think that you, your company, or anyone else owns a patent or other IPR on 
the work described in the draft, you should read carefully RFC 3979[RFC3979]. 
The first notice required in Internet-Drafts, described in Section 3 of this 
document, obligates you to send an IPR disclosure under certain circumstances. 
Before submitting the draft, it would be a good advice to talk to the working group 
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10. Further Reading 

The IETF process is described in RFC 2026[RFC2026]. The IETF rules concerning 
copyright are described in RFC 3978[RFC3978]. The IETF rules on IPR are 
described in RFC 3979[RFC3979]. RFC 3978 and 3979 are updates to RFC 2026 
and obsolete section 10 of that document. This document is for helping authors. If 
you need the definitive rules, read RFC 2026, RFC 3978 and RFC 3979. 

More good references when submitting a document to the IESG for publication as 
an RFC are the web page on Submitting Internet-Drafts to the IESG 
(< http://www.ietf.org/ID-Checklist.html >), the RFC Editor's Web pages on 
how to publish an RFC (<http:/ /www.rfc-editor.o r g/howtopub.html >), and 
the Instructions to RFC Authors ([I-D.rfc-editor-rfc2223bis]). Henrik Levkowetz 
has written an excellent tool that checks many of these requirements; it is 
available at <htt p://ietf.levkowetz.com/tools/idnits/ >. 

There are several tools to help the process of writing an Internet-Draft in this 
format; the RFC Editor has collected several pointers on their web page 
(<http:/ /www.rfc-editor.or g /formattin g. htm l > ) . 
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• Update all references from RFCs 3667/3668 to 3978/3979. 

• Update IPR boilerplate with words from RFC3978. Add a note that it's not 
appropriate to change the boilerplate, even if it seems wrong. 

• Make it clear in the IPR section that the author is required to disclose IPR 
under certain circumstances by the 3978/3979 boilerplate. 

• Add "Any submission which does not include these statements will be 
returned to the submitter. The IETF Secretariat will NOT add this text." to the 
section on Internet-Draft boilerplate too. 

• Spell out exactly how drafts are named. 

• Remove the option of asking the secretariat for an Internet-Draft name. 

• Add the option for an author to un-expire or extend the expiration date of an 
Internet-Draft. 

• Treat Postscript and PDF the same. 

• Say "254mm" instead of "10 inches" since we're talking about metric paper 
sizes. 

• Fix minor typos and make some wording changes in the section on Abstracts, 
making the text closer to 2223bis. 

• Include documentation on the I-D deadline and how to check on I-Ds 
submitted near the deadline. 

• Add a pointer to the RFC-Editor's formatting web page. 
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• Individual Drafts by Author Identifier abcdefghijklmnppqrstuvvyxy. z other 

» Other Drafts IAB IANA I ASA IESG [RTF PROTO RFC EDITOR TOOLS 



• I-D Search 



I-Ds List, Author identifier starts with draft-f 



Please click a document below to view detail information 






I-D Filename and Version 
Number 


Submission Date Status 


RFC# 


I-D Tracker State 


draft-faber-time-wait-avoidance- 
00 


1997-09-11 


Expired 




ID Exists 


draft-faccin-mih-infoserv-02 


2006-03-08 


Active 




ID Exists 


cfraft-faerber-http-content-disp- 
Q0 


1998-09-22 


Expired 




ID Exists 


draft-faerber-il 8n-email- 
netnews-names-00 


2002-08-29 


Expired 




ID Exists 


draft-fair-ipdvb-ar-04 


2005-04-12 


Expired 




ID Exists 


draft-fair-ipdvb-req-05 


2004-06-08 


Expired 




ID Exists 


draft-fair-ipdvb-ule-02 


2003-11-24 


Expired 




ID Exists 


draft-fairhurst-ipdvb-s2-gule-04 2006-01 - 1 8 


Active 




ID Exists 


draft-fairlie-nimusic-sdp-sctp-00 


2001-05-10 


Expired 




ID Exists 


draft-fairlie-sipping-netapp- 
session-00 


2002-06-05 


Expired 




ID Exists 


draft-fairman-rtp-6 1 883-00 


2003-06-19 


Expired 




ID Exists 


draft-fajardo-dime-interop-test- 
suite-00 


2006-02-27 


Active 




ID Exists 


draft-fakih-amdp-00 


2003-01-30 


Expired 




ID Exists 


draft-falk-xcp-spec-01 


2005-10-20 


Active 




ID Exists 


draft-falkner-nfsv4-acls-00 


2005-10-17 


Active 




ID Exists 


draft-faltstrom-el 64-06 


2000-01-31 


Expired 




ID Exists 


draft-faltstrom-i 1 8n-sorting-00 


2001-11-20 


Expired 




ID Exists 


draft-faltstrom-macmime-00 


1993-09-27 


Expired 




ID Exists 


draft-faltstrom-macmime 1-01 


1994-02-15 


RFC 


1740 


ID Exists 
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draft-faltstrom-macmime 1 -v2- 
0.1 

draft-Mtstra^ 

draft-faltstrom-macmime2-v2: 
00 

draft- faltstrom-registrv-registrar- 
00 

draft-faltstron^ 
s ynchronisation-00 
draft-faltstrom-whois-05 
draft-fan -mpl s-lambda- 
sig na l i ng-00 
draft-fan-nfsv4- g lobal- 
namespace-00 

draft-fang- d iffserv-tc-t swt c m-00 
d r aft-fang-ppvpn-sec ur ity- 
framework-01 

draft-fangman-ryon-dhc-hqos-00 
draft-farah-adntf-adns- 
g uid e l in es-0 1 

draft-fara h -new-keywords-02 
draft-farah-u ggc- protocol-0 1 
draft-farinacci-anycast-clusters- 

01. 

draft-farinacc i- bid i r- p im -01 
draft-farinacci- m pls -m ulticast- 
Q3 

draft-farinacci-msdp-00 
draft-farin a cci- mu lticast-label- 
par t- 01 

d raft-f a rina c ci- mu lti ca st-tag- 
part-00 

draft-farinacci-multicast-tagsw- 
01 

draft-fannacci-pim 

draft-farinacci-pim-pop -count- 
00 

draft-farrel-ccamp-ifid-unnum- 
00 

draft-farrel-ccamp-inter-domain 
framewo rk - 01 
draft- f arrel-mpl s-I dp -ft -00 
draft-farrel-mpls-ldp-restart- 
ap plic-01 

d raft- far rel-nipl s- preeniption-01 
draft-f^^ 
interim-00 



1995-12-13 


Expired 




ID Exists 


1993-10-15 


RFC 


1741 


ID Exists 


1995-11-22 


Expired 




ID Exists 


2001-06-14 


Expired 




ID Exists 


2003-12-02 


Expired 




ID Exists 


2000-05-02 


Expired 




ID bxists 


2000-02-29 


Expired 




ID Exists 


2005-03-28 


Expired 




ID Exists 


2000-03-13 


RFC 


2859 


ID Exists 


2003-07-01 


Expired 




ID Exists 


>2002-04-29 


Expired 




ID Exists 


2006-03-10 


Active 




ID Exists 


2001-01-31 


Expired 




ID Exists 


2001-01-31 


Expired 




ID Exists 


1998-03-09 


Expired 




ID Exists 


1999-06-18 


Expired 




ID Exists 


2000-11-29 


Expired 




ID Exists 


1 998-06-29 

1770 uv £*J 






Dead 


1999-08-31 


Expired 




ID Exists 


1996-12-16 


Expired 




ID Exists 


1998-11-16 


Expired 




ID Exists 


2003-01-22 


Expired 




ID Exists 


2004-05-18 


Expired 




ID Exists 


2004-02-02 


Expired 




ID Exists 


2004-07-12 


Expired 




ID Exists 


2000-02-16 


Expired 




ID Exists 


2002-10-14 


Expired 




ID Exists 


2004-04-09 


Expired 




ID Exists 


2003-12-02 


Expired 




ID Exists 
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draft-farrel-problem-protocol- 
icrm-00 


2003-06-11 


Expired 


ID Exists 


draft-farrel -rtg-manageab il ity - 
requirements-01 


900S-10-97 


tWs 11 V C 


TF) FYictc 


draft-farrel -rtg-moralitv- 
requirements-01 


100A 19 09 


P YtllfPn 

r>xpircu 




draft-farrel l-sacred-00 


2000-07-12 


Expired 


ID Exists 


draft-faurite-rmt-tesla-for-alc- 
norm-01 


2006-02-27 


Active 


ID Exists 


draft-favnberg-intermediarv- 
transport-00 

Sr- 


2003-02-25 


Expired 


ID Exists 


draft-favnberg-spirits-inpintreqs- 
02 


: 2000-1 1-10 


Exnired 

J //v Ly I. J. wU- 


ID Exists 


draft-favnbera-spirits-protocol- 
00 


1 QQQ 1 0 1 S 


h vntrpn 

H/Apii cu. 


TT"^ F vi etc 


draft-faynberg-spirits-reqs-00 


2001-02-08 


Expired 


ID Exists 


draft-favnberg-telephone-sw- 
net-00 


1997-03-05 


Expired 


ID Exists 


draft-feather-hashed-uri-03 


2002-09-17 


Expired 


Dead 


draft-fecvk-dmp-02 


2004-05-05 


Expired 


ID Exists 


draft-fecvk-dsprotocol-04 


2003-08-26 


Expired 


ID Exists 


draft-fedvk-bgpvpon-auto-00 

j or 1 — r= 


2001-02-27 


Expired 


ID Exists 


draft-fedvk-gmpls-ethemet-ivl- 
00 


2005-10-20 


Active 


ID Exists 


draft-fedvk-isis-ospf-te-metrics- 
01 


9000-1 1 -91 




TD Fxi<?t<; 


draft-fedvk-1 1 vpn-basic-mode- 
01 


2006-03-07 


Active 


ID Exists 


draft-fedvk-mpls-te-metrics-00 


1999-10-22 


Expired 


ID Exists 


draft-feher-benchresres-00 


2000-07-20 


Expired 


ID Exists 


draft-feher-bmwg-benchres- 
method-00 


9001-07-16 


"F Ymrfn 


TF) Fvist^ 


draft-feher-bmwg-benchres- 
term-00 


2000-12-19 


Expired 


Dead 


draft-feiehery-ip-over-ccsds-00 


2003-11-18 


Expired 


ID Exists 


draft-feil-sitp-0 1 


1992-06-02 


Expired 


ID Exists 


draft-feiten-avt-bsacmode-for- 
rfc3640-00 


2005-02-11 


Expired 


ID Exists 


draft-feldman-aris-spec-00 


1997-03-26 


Expired 


ID Exists 


draft-feldman-ldp-spec-00 


1997-12-02 


Expired 


ID Exists 


draft-feldman-mpls-atmvp-00 


1999-03-01 


Expired 


ID Exists 


draft-felton-universal-language- 
01 


2001-04-26 


Fxnired 

.L^/v L/ll \*W 


ID Exists 


draft-feng-dp-services-00 


1998-06-02 


Expired 


ID Exists 


draft-fenner-igmp-iana-0 1 


2001-09-20 


Expired 


ID Exists 


draft-fenner-literal-zone-02 


2005-10-24 


Active 


ID Exists 


draft-fenner-traceroute-ipm-0 1 


2005-02-15 


Expired 


ID Exists 
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